As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to these users is an information handling system. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may vary with respect to the type of information handled; the methods for handling the information; the methods for processing, storing or communicating the information; the amount of information processed, stored, or communicated; and the speed and efficiency with which the information is processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include or comprise a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
A data processing network may include two or more information handling systems that are coupled to one another and work in concert to process data. One or more of the information handling systems in the data processing network may be a server. A service processor may operate as the system administrator and may be used to regulate operation of the information handling systems in the data processing network. In certain applications, the service processor may schedule Out of Band (“OOB”) jobs. Such OOB jobs may include, but are not limited to, configuration of system devices (e.g., Network Interface Card (“NIC”), Redundant Array of Independent Disks (“RAID”), Basic Input/Output System (“BIOS”), etc.) or firmware updates. The OOB jobs typically require a system reboot followed by launching a pre-boot system management application to perform the desired update or configuration task. For instance, the pre-boot system management application may be a UEFI based application like Lifecycle Controller available from Dell™. The OOB job is then performed and the system is rebooted again to launch back into the Operating System.
OOB jobs are usually scheduled by users or executable scripts from their remote clients sending specific requests, such as requests for configuration of a specific device or updating it's firmware, to the service processor. The information handling system that sends this request is referred to herein as the “host”. Upon the receipt of such requests, the service processor then schedules a task (referred to herein as an “OOB job”) which is to be executed on a different data processing network such as a server in a specific time window. The information handling system on which the OOB job is executed is referred to as the “OOB Client”. Following is a description of the sequence of operations on the server data processing network from the time it reboots until it executes such OOB jobs.
FIG. 1 depicts a method of handling OOB jobs by a typical data processing network in accordance with the prior art. First, at step 102 a host (e.g., an information handling system such as a server) may transmit a boot option query to a service processor. The service processor returns the current boot options to the host at step 104. It is then determined at step 106 whether the current boot option identified by the service processor is an OOB job. If the current boot option is not an OOB job, the process proceeds to step 108 and the host boots to the Operating System.
On the other hand, if at step 106 it is determined that the current boot option identified by the service processor is an OOB job, the host prepares to execute such jobs. At step 110 the Option ROMs and Pre-boot environment drivers (“driver(s)”) for all devices of the host are typically loaded, regardless of whether the device is one that is being configured and/or updated by the OOB job. The OOB job is then performed by the host at step 112 and the system reboots at step 114.
Depending on the number of devices present in the host, the time required for loading Option ROMs and drivers for all devices may be significant. With the evolution of information handling systems, it is desirable to maximize operational efficiency of the system and minimize system downtime. Accordingly, the contribution of current OOB jobs to system downtime adversely impacts overall system performance. Moreover, loading the Option ROMs and drivers for all devices renders the OOB job susceptible to unnecessary errors. For instance, if a device not participating in the requested OOB job has a corrupt Option ROM or driver it can cause an unexpected system behavior and delay job execution.